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ABSTRACT 
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Reuse : Background and concepts. 

Software Reuse is one of the technologies that is currently 
presented as being able to solve the so-called “Software Crisis”. In 
this section, we will describe some of the key concepts of this 
technology, the different approaches to reusability, some of the 
issues related to it, and we will try to present how the Engineering 
Script Language (ESL) implement the reuse paradigm. 

Reuse Concepts 

The primary goal of reusing software components is that 
software can be developed faster, cheaper and with higher quality. 

Though, reuse is not automatic and can not just happen. It has to be 

carefully engineered. For example a component needs to be easily 
understandable in order to be reused, and it has also to be malleable 
enough to fit into different applications. In fact the software 

development process is deeply affected when reuse is being applied. 
During component development, a serious effort has to be directed 
toward making these components as reusable as possible. This 

implies defining reuse coding style guidelines and applying them to 
any new component to create as well as to any old component to 
modify. These guidelines should point out the favorable reuse 
features and may apply to naming conventions, module size and 
cohesion, internal documentation, etc... During application 
development, effort is shifted from writing new code toward finding 
and eventually modifying existing pieces of code, then assembling 
them together. We see here that reuse is not free, and therefore has 
to be carefully managed. 


Approaches to Reuse 

There are two different approaches to reusing software 
components: Adaptive Reuse and Compositional Reuse. Their 

characteristics are as follow: 

• Adaptive Reuse 
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With this approach, components are templates or patterns and are 
changed each time they are used. 

• Compositional Reuse 

components are atomic and don’t change when they are used. 


Issues / Dilemmas 

The operational problems of reusability are the following: 

• finding components 

• understanding components 

• modifying components 

• composing components 

When a programmer has to develop a piece of code, the first 

thing he does is to look in the library of available components to 

check if there is one that matches his needs. This search process 
needs to be able to find not only the exact match, but also the “close 
enough” type of components if the ideal one does not exist. The 
difficulty of this step is directly linked to the breadth of the library 
of components. The more specific are the components, the more 
numerous they will be in the library, and the more difficult it is to 

find the appropriate one. This aspect of the reuse process is dealt 

with library systems. 

Understanding a component is the next step the programmer 
will go through, in order to be able to use properly the component he 
found during the search process. If modifications are necessary, i.e. if 
the component does not match exactly the need of the programmer, 
the understanding is even more important as he will need to enter 
into the code and change it. For this understanding process to be 
successful, there needs to be a lot of emphasis on documentation 
during design and coding of any reusable component. 

Modification of components is the step that seems to be the less 
automatizable. The programmer has to do his work at customizing 
the component to his needs. The issue that is related to this step is 
that we can foresee that many components may be spawned out of a 
common root component in order to customize it to the different 
needs of different programmers. The only way to prevent the library 
to get out of control is to build components that are generic enough 
to be applied to many different situation. 

Composing components is the step that is completely specific to 
the reuse-based software development process. Once all the needed 
components have been found, eventually modified, or developed 
from scratch, there needs to be a framework where the programmer 
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can specify how to compose these components together to build the 
targeted application. 

ESL vs Reuse 

The ESL concept of Reuse is based on the following principles: 
ESL is targeted toward domain specialists who do not have a 
sufficient knowledge of Ada programming language to develop code 
in their domain. The tool would allow them to graphically develop an 
application from the available pieces of code stored in a software 

component library. We should point out here, that the ESL system 

does not address the issue of developing the elementary components 

that are populating the library. It takes as a first assumption that 
these components exist, that they are medium to gross grain 

components written in Ada, and that they were input in the 

knowledge base with the proper amount of information to allow their 
retrieval and their correct use. Based on these assumptions, ESL 
contains the different mechanisms that allows an application 
developer to build the program he needs from the stored 

components. Let us now focus on the different parts of ESL: 

• The first part of ESL deals with the storage of the components. The 
system is built on a knowledge base written in ART-IM. This 
knowledge base contains the important information about the 
components such as what it does, what the inputs and outputs are, if 
the component is composed of other components or if it is an 
elementary one. 

• The second part of ESL addresses the issue of retrieving a 

component. ESL has a Case Base Reasoning (CBR) engine that allows to 
query the library for components having some similarities with the 
needed component. The system will present a list of components 
belonging to the same class, ordered according to the number of 
identical attributes values. The application developer can refine his 
query by analyzing the closest component, changing the unfit 
attributes and then resubmitting the query with the added 

information. 

• The third part of ESL focus on assembling the retrieved 
components in order to build an application. A graphical editor 
allows the application developer to graphically link the desired 
components. 

• The fourth part of ESL is the code generator. From the graphical 
representation of the flow of inputs and triggers through the 
different components, ESL generates an Ada main program that 
contains the calls to the different routines chosen by the user. 
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1.1 Description of the ESL Reuse method 

The Engineering Script Language (ESL) is a language designed to 
allow non programming users to write High Order Language (HOL) 
programs by drawing directed graphs to represent the program and 
having the system generate the corresponding program in HOL. For 
the implementation of ESL proposed, the HOL code to be generated 
will be Ada. 

The building blocks for directed graphs are nodes and connectors. 
Nodes are visually represented as labeled icons (e.g., rectangles or 
circles) and have input and output ports which are used to receive 
produce data. On a graph, an output port from one node may be 
connected to an input node on another node via a connector. Visually, 
all connectors passing data between two nodes are represented as a 
single arrow connecting the icons representing the nodes. In addition, 
a graph itself can have input ports and Output ports which are 
connected to ports or nodes on the graph. Visually, the set of all 
graph input ports is represented by a single icon on the left of the 
editor window. Each arrow from this icon to a node on the graph 
represents a group of connectors. Similarly, the set of all graph 
output ports is represented visually as a single icon on the right of 
the editor window. 

Each node on a graph may represent a primitive procedure or 
function in the HOL (i.e., a primitive subprogram), an ESL control or 
data-passing mechanism, or another graph. When a node is a 
primitive subprogram node, the node’s ports represent the 
subprogram’s parameters and, if applicable, its return value. 


Node Objects 

There are several classes of node objects: the subprogram node, 
(which includes procedure-node, function-node, and subgraph-node 
objects), the Merge node, the Replicator node, and the control nodes 
(If, Select, and Iterator). 

A subprogram-node object is used to represent a procedure or 
function coded in the HOL or to represent a graph previously created 
through the ESL editor. Each subprogram- node object points to a 
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subprogram object. Subprogram objects are objects visible through 
the ACCESS tools panel and included in the ACCESS taxonomy. 


Subprogram objects have corresponding ports. Ports of a procedure 
or a function object represent parameters of the corresponding 
procedure or function or the return value of the function. Ports of a 
graph object, called graph ports, are mapped to ports on nodes of the 
graph by connector objects. 


Implementation Objects 

An implementation object contains information about how a 
subprogram object is implemented. The merge, replicator. If, Select 
and Iterator nodes each have an implicit implementation and do not 
have an associated implementation object. There are three classes of 
implementation objects.: In line, separately compiled procedure, and 
package. 

In line implementation objects are appropriate only for graph 
objects. This type of implementation means that when a subgraph 
node is part of a larger graph for which code is generated, the code 
corresponding to the subgraph node is generated online. 

Implementation objects whose type is separately compiled procedure 
are valid for all subprogram objects. Such an implementation object 
indicates that the subprogram is implemented as a separately 
compiled Ada procedure. For a separately compiled procedure to be 
called by an Ada program, the program must be first "with" the 
procedure; then the procedure may be called. 

Package implementation objects are valid for subprograms of 
procedure or function type. Such an implementation object indicates 
that the subprogram has been implemented as a visible function in 
an Ada package. For a procedure or function in a package to be called 
by an Ada program, the program must first "with" the package; then 
the procedure may be called using the "package. procedure" notation. 
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Object Hierarchy 

The following is the hierarchy of objects in ESL system. 

subprogram 

primitive subprogram 
function 
procedure 

graph 

node 

subprogram node 

primitive subprogram node 
procedure node 
function node 
subgraph node 
merge node 
replicator node 
control node 
if node 
select node 
iterator node 

port 

graph port 
procedure port 
function port 
node port 
connector group 
connector 
implementation 

in line implementation 

separately complied procedure implementation 
package implementation 
data type 
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Figure 1.1.1 shows the various steps that would be involved in 
building a complete application with the help of a Parts Composition 
System (PCS), as currently envisioned. A library of procedures (or 
more generically, primitives) containing software parts that are 
needed by most application programs within the domain of interest 
is opened and scanned. If this library contains most of the required 
primitives, then the application developer may select to use it; 
otherwise, additional libraries may be searched. 


Depending on the decisions of the libraries' management 
organizations, application developers may or may not be allowed to 
create modified versions of primitives in the libraries. However, the 
development, organization, and maintenance of these domain-specific 
libraries is primarily the responsibility of the software development 
engineers and not the job of the application developers, who may 
well be aerospace engineers with minimal programming experience. 
The software development engineers receive part specifications from 
the application developers and provide implementations to populate 
required libraries. If well managed, this seperation of roles helps to 
limit the amount of domain expertise that the software engineer 
must have and also the amount of programming experience that the 
application developer must have. 
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The construction of primitives can be done using the Computer- 
Aided Software Engineering (CASE) tools. However, a useful, well- 
maintained library of reusable parts consists of more than a 
disorganized jumble of parts. A librarian and library tools are clearly 
required. A librarian must build and maintain a PCS knowledge base 
using tools that extract the necessary metadata from each primitive 
(such as input, output, purpose, and constraints) and then catalog this 
information with the knowledge base s schemas. The cataloging 
process includes the assignment of each primitive to a specific 
knowledge base class. Careful development of a meaningful class 
structure is essential to the usefulness of the library's catalog and 
one of the most challenging tasks of the knowledge engineer. Special 
displays may also be required for some classes of primitives in order 
to make the catalog as user friendly as possible. In short, the 
knowledge engineer must build an IUI for each domain-specific 
library of reusable parts. His/her role is to serve as the intermediary 
between the software development engineers and the application 
developers. 

Once an application developer has selected the most appropriate 
domain- specific library of parts, he/she invokes the ESL editor. As 
already explained, the ESL editor allows the application developer to 
create, modify, store and retrieve graphs that represent applications. 
The graphs show the structure of an application and what data 
controls and constraints flow between the components (fig. 1.1. 2) The 
components are depicted by boxes called nodes, and the data 
controls, and constraints are shown as arrows linking the nodes. 

Other structures, also called nodes, allow for merging and replicating 
links and for including looping and branching logic. Each component 
(box) is either a primitive or a subgraph, which makes possible 
hierarchical decomposition, (fig. 1.1. 2) 

With ESL editor, an application developer uses a mouse and pointer 
to select menu and palette commands and to select nodes and links 
on the screen. In this way, graphs are constructed, modified, and 
stored for possible reuse. 
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Fig. 1 .1 .3 Hierarchical Decomposition of ESL graphs 

Once the graphs representing an application are completed, the 
application developer will invoke menu commands to validate the 
graph system and to generate the required code in some high order 
language, such as Ada. The generated code, in the form of a main 
program and subprograms, will then be ready to be compiled and 
linked with the object code of the primitives from the domain 
specific library(ies). Alternatively, source code templates (such as 
Ada generics or even main programs with certain parameters that 
must be initialized before compilation) might be generated, if 
required. 
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ESL graphs will be stored in a knowledge base, where they will be 
represented, using a schema system, as objects with attributes. The 
ability to store and retrieve ESL graphs implies a need for well- 
organized, domain-specific libraries of graphs with good library 
catalogs. Just as in the case of the libraries of primitives, a knowledge 
engineer will need to create IUI s for the ESL graph libraries. 

The internal representation and storage of graphs, the semantic 
interpretation and validation of the graphs, and the generation of 
code in high order language are done using knowledge-based 
technology. 


Graph Implementation and Execution 

Fig 1.1.4 depicts a typical example graph created using the ESL editor 
panel. Each box is an instance of an object. In other words each box is 
merely a procedure call or a function call. The iterator node indicates 
an iteration at that particular point until a certain condition is 
satisfied. INNER.LOOP is a sub graph attached to the main graph. It is 
a separately edited graph. The sub graph is shown in fig. 1.1.5. 

Prior to executing a complete application, the graphs must be 
translated to a high order language (HOL) representation and 
subsequently compiled. A graph implementation is an HOL 
representation of a hierarchical ESL data flow graph that can be 
compiled by a standard HOL compiler for subsequent execution. The 
translation process generates the graph implementation by mapping 
the features found in the application's graph schemas to predefined 
HOL constructs. 


10 



Fig. 1.1.5 ESL sub graph for INNER_LOOP 
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Generated Code 

- Ada code for graph six_dof_driver 


with ASDS_Exec_Record_Manager; 
with six_dof_driver_inner; 
wth Environment_model; 
with Six_Dof_lnstantiations; 

With statejypes; 

procedure six_dof_driver is 

TESTIS : Boolean := TRUE; 

Exec 15 : ASDS_Exec_Record_Pointer_type; 

Exec20 : ASDS_Exec_Record_Pointer_type; 
Num_Diff_Eq16 : Positive; 

Exec 17 : ASDS_Exec_Record_Pointer_Type; 
Exec 19 ; ASDS_Exec_Record_Pointer_Type; 


begin 

-- Code for node Get Exec 1 

Exec15 := Six_DOF_lnstantiations.Get_Exec; 

- Code for node Set ptr to rec 

ASDS_Exec_Record_Manager.set_pointer_to_ASDS_EXEC_record(Exec15); 

-- Code for node Set Evts 
Six_DOF_lnstantiations.Sst_Discrete_Events; 

-- Code for node Get Input 1 

Six_DOF_lnstantiations.Six_DOF_INPUT.Get_lnput; 

-- Code for node Get Exec 2 

Exec19 ;= Six_DOF_lnstantiations.Get_Exec; 

-- Code for node Get End of Run 1 

TestlS := Six_DOF_lnstantiations.Get_End_Of_Run(Exec19); 

- Code for ITERATE 
while (TEST 18) loop 

~ code for node Compute Num of DEs 

Num_Diff_Eq16 := State_Type.Compute_Num_Of_Diff_Ef; 

— Code for node Get Exec 3 

Exec17 := Six_DOF_lnatantiations.Get_Exec; 

- Code for node Set Num DEs 

Six_DOF_lnstantiations.Set_Num_Diff_Eq(Exec17, Num_Dlff_Eq16); 
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- Code for node inner loop 
Six_dof_driver_inner; 

- Code for node Get Input 
Six_DOF_lnstantiations.six_DOF_lnput.Get_lnput; 

- Code for node Get Exec 

Exec20 := Six_DOF_lnstantiations.Get_Exec; 

-- Code for node Get End of Run 

TESTIS := Six_DOF_lnstantiations.Get_End_Of_Run(Exec20); 
end loop; 

end six_d of _d river; 


1.2 Methods used to reengineer FM tool kit code to ESL Reusable 
Method. 


As described in section 1.1, we know that the code generated by a 
designed graph in the ESL system, would be either a main program 
or a sub program. Also we have mentioned , that a main program or 
a sub program can be a single procedure or a function call or a set of 
procedure or function calls or a set of procedure and function calls. 
In addition, a main program or a sub program can have loop 
structures and if-then-else structures. An important point is that, 
ESL does not support nested loop structures. This is one of the 
limitations provided in the ESL system. Hence, primarily, we need to 
realize that, reengineering any application should be done within 
this limited ESL framework. 


Currently FM tool kit said to have eleven applications. These source 
code have been developed in Ada. These applications look very 
similar. For our "reengineering-for-ESL" purposes, four of these 
applications - namely INTRPLAN, IPCAPTUR, BEST1WAY and 
POWRSWNG , have been randomly selected. A vital part of the 
"reengineering-for-ESL" process is to develop a library of procedures 
(or more generally, PRIMITIVES) containing the reusable software 


13 


components , so that they can be put together to form a complete 
application. 

Analysis of FM-Tool kit applications 

Initially, let us consider the two applications INTRPLAN & IPCAPTUR. 
The code shown below (Fig. 1.2.1 & Fig. 1.2.2) depicts the main 
programs of the above two applications. 


with INTRPLEC ; use INTRPLEC ; 
with INTRPLIO ; use INTRPLIO ; 

procedure INTRPLAN is 

begin 

RETR I EVE_PREVI OUS_ I NPUTS_FROM_D I SK 
LET_USER_ED I T_I NPUT.DATA 
SAVE_ED I TED_ I NPUTS_ON_D I SK 

SET_UP_CON ST ANTS_AND_P LANETARY_EPHEMER IDES 

DISPLAY_DATA_SHELL ( NOM I NAL_DE PARTURE_DE LT A_V ) 

for J in 0 . . 10 loop 

COMPUTE_POSITION_AND_VELOCITY_OF_TARGET_PLANET { J ) 

for I in 0 . . 1 6 loop 

COMPUTE_POSITION_AND_VELOCITYJDF_HOME_PLANET { I ) 
COMPUTE_TRAJECTORY_DATA { I, J ) 

D I S P LAY_VALUE ( NOMINAL_DEPARTURE_DELTA_V f I, J ] 
CHECK_FOR_INTERRUPT_FROM_KEYBOARD 
end loop 
- end loop 

DISPLAY_TRAJECTORY_DATA_OF_INTEREST_TO_USER 

end 


Fig 1.2.1 - Main Program for INTRPLAN 


with I PCAPTEC ; use IPCAPTEC ; 
with IPCAPTIO ; use IPCAPTIO ; 

procedure IPCAPTUR is 


begin 

RETRIEVE_PREVIOUS_INPUTS_FROM_DISK 

LET_USER_EDIT_INPUT_DATA 

SAVE_EDITED_INPUTS_ON_DISK 

SET_UP_CONSTANTS_AND_PLANETARY_EPHEMERIDES 

DISPLAY_DATA_ SHELL ( NOMINAL_DEPARTURE_DELTA_V ) 

for J in 0 . . 10 loop 

COMPUTE_POSITION_AND_VELOCITY_OF_TARGET_PLANET { J ) 

for I in 0 . . 16 loop 

C OMP,UTE_PO S I T I ON_AND_VELOC I TY_OF_HOME_P LANET ( I ) 
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COMPUTE JTRAJECTORY_DATA ( I, J ) 

DISPLAY_VALUE ( NOMINAL JEPARTUREJELTA_V , I, J } 

CHECK_FOR_INTERRUPT_FROM_KEYBOARD 
end loop 
end loop 

DISPlAY_TRAJECTORYJATA.OF_INTEREST_TO.USER 

end 


Fig 1.2.2 - Main program for IPCAPTUR 


The two main programs look exactly the same, except for the 
different dependent library units, (i.e intrplec & intrplio for 
INTRPLAN and ipcaptec & ipcaptio for IPCAPTUR). In ESL terms 
these two are non primitives , because they do not have any 
computational instructions but a set of module calls. Therefore a 
major modification is not required except for the elimination of the 
FOR loops. ( In ESL, nested looping structures are not allowed.). 

A simple solution to this is to incorporate the inner FOR loop in a 
separate module and isolate it. Then the two main program 
structures will look as follows. 


with IPCAPTEC ; use IPCAPTEC ; 
with IPCAPTIO ; use IPCAPTIO ; 

procedure IPCAPTUR is 

begin 

RETR I EVE.PREVI OUS_ I NPUTS_FROM_D I SK 
L ET_U S ER_ED I T_ INPUT JATA 
SAVE_ED I TED_ I NPUTS_0N_D I S K 
SETJP_CONSTANTS_AND_PLANETARy_EPHEHERIDES 

D I S P LA Y_DAT A_S HELL ( TOTAL JELTA_V ) 

for J in 0 . . 10 loop 

COMPUTE JOS ITION_AND_VELOC ITYJF_TARGET_PLA NET ( J ) 

INNER_LOOP; 
end loop 

D I SP LAY_TRA JECTORYJAT A_0F_INTER EST_T0_U S ER 
end 


FIG. 1.2.3a 


with INTRPLEC ; use INTRPLEC ; 
with INTRPLIO ; use INTRPLIO ; 
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procedure INTRPLAN is 


begin 

RETRIEVE_PREVIOUS_INPUTS_FROM_DISK 

LET_USER_EDIT_INPUT_DATA 

SAVE_ED I TED_INPUTS_ON_D I SK 

SET_UP__CONSTANTS_AND_PLANETARY_EPHEMERIDES 

DISPLAY_DATA_SHELL ( NOMINAL_DEPARTURE_DELTA_V ) 

for J in 0 . . 10 loop 

COMFUTE_POS IT ION_AND_VELOC ITY_OF_TARGET_PLANET { J ) 

INNER_LOCP; 
end loop 

DISPLAY_TRAJECTORY_DATA_OF_INTEREST_TO_USER 

end 


FIG. 1.2.3b 


procedure INNER_LOOP is 
begin 

for I in 0 . . 16 loop 

COMPUTE_POSITION_AND_VELOCITY_OF_HOME_PLANET ( I ) 
COMPUTE_TRAJECTORY_DATA { I, J } 

D I S P LAY_VA LUE ( TOTAL_DELTA_V , I, J ) 

CHECK_FOR_INTERRUPT_FRdM_KEYBOARD 
end loop 
end INNER_LOOP; 


FIG. 1.2.3c 


The module INNERJLOOP is the newly created module in order to 
incorporate the inner FOR loop in the original main program of both 
INTRPLAN and IPCAPTUR. As a matter of fact , this new procedure 
automatically have become a reusable component. Further, the new 
main program is just a set of module calls with one single loop 
structure. But the FOR loop must be changed to a WHILE loop as to 
fulfil ESL requirements. We have discussed this later in this section. 

The above modification is inadequate. Of interest to us is whether, 
the modified main programs INTRPLAN and IPCAPTUR can be 
represented in an ESL graph. A straight answer is NO. Still we need 
to change the outer FOR loop structure. We can think of replacing the 
outer FOR loop structure with a WHILE loop structure as ESL 
supports WHILE loops. In order to do this, the value of J must be 
incremented inside the WHILE loop. This can be implemented with a 
simple computational statement like J := J + 1; 


with IPCAPTEC ; use IPCAPTEC ; 
with IPCAPTIO ; use IPCAPTIO ; 

procedure IPCAPTUR is 
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LOCP_END : boolean := FALSE; 

J : .integer : = 1; 
begin 

RETRIEVE_PREVIOUS_INPUTS_FROM_DISK 
LET_US ER_ED I T_INPUT_DATA 
S AVE_SD I TED — INPUT S_ON_D I SK 

SE7_UP_C0NSTANTS_ANB_PLANETARY_EPHEMERIDES 

DISPLAY_DATA_SHELL ( TOT A L_DE LTA_V ) 

while LOCP_END = FALSE loop 

COMPUTE__POS IT ION_AND_VELOC I TY_OF_TARGET_P LANET { J ) 

INNER_LOOP; 

J : = J i- 1 ; 
if J > 10 then 

LOOP_END := TRUE; 
end if; 
end loop 

DISPLAY_TRAJECTORY_DATA_OF_INTEREST_TO_USER 

end 

FIG. 1.2.4 


The above is the modified main program code for IPCAPTUR. 
(Considering the main program of IPCAPTUR is good enough for the 
time being). Changing the inner FOR loop into a WHILE loop caused 
us to incorporate few other additional statements ( FIG. 1.2.5) within 
the WHILE loop. 


J : = J + 1 ; 
if J > 10 then 

LOOP_END : o TRUE; 
end i f ; 


FIG. 1.2.5 

Added Computational Statements inside the WHILE loop 


The question is whether the modified main program shown in figure 
1.2.4 is good enough to construct an ESL graph. Again, a straight 
answer is NO. The simple reason is that, there cannot be any 
computational statements within a piece of code except for a set of 
module calls , to construct the corresponding ESL representation. 
Hence a solution is to further decompose the main-program (of 
INTRPLAN & IPCAPTUR); meaning, removing the outer FOR loop and 
incorporate it in a separate module, and call that module from the 
main program. The figure 1 .2.6 shows the final picture of the main 
program for INTRPLAN and IPCAPTUR. 


with IPCAPTEC ; use IPCAPTEC ; 
with IPCAPTIO ; use IPCAPTIO ; 
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procedure IPCAPTUR is 


begin 

retrieve_previous_inputs_from_disk 
LET_US ER_ED I T_INPUT_DATA 
SAVEJDITED_INPUTS.ON.DISK 

SET_UP_C ON S T ANT S_AND_P LANETAR Y_E PHEMER IDES 
DISPLAY_DATA_SHELL ( TOTAL_DELTA_V 

MAIN_LOOP; 

D I S P L A Y_TRA J EC TO R Y_DATA_OF_I NTER EST_TO_U S ER 
end 


FIG* 1.2.6a 


with INTRPLEC ; use INTRPLEC ; 
with INTRPLIO ; use INTRPLIO ; 

procedure INTRPLAN is 

begin 

RETRIEVE _PREVIOUS_INPUTS_FROM_DISK 

LET_USER_EDIT_INPUT_DATA 

SAVE_EDITED_INPUTS_ON_DISK 

SET_UP_CONSTANTS_AND_PLANETARY_EPHEMERIDES 

DISPLAY_DATA_SHELL { NOMINAL_DEPARTURE_DELTA_V ) 

MAIN_LOOP; 

DISPLAYJTRAJECTORY_DATA_OF_INTEREST_TO_USER 

end 


FIG. 1.2.6b 

where MAIN_LOOP is the newly created procedure to incorporate the 
outer loop in the main program(s) (FIG 1.2.7). 

procedure MAIN_LOOP is 


begin 

for J in 1 . . 10 loop 

C0MPUTE_P0 S IT I ON_AND_VE LOC ITY_OF_TARGET_P LANET ( J ) 
INNER_LOOP; 
end loop; 

end MAIN_LOOP; 


FIG. 1.2.7 

The final main program(s) is purely a set of module calls and within 
ESL requirements. The ESL graphical representation to create the 
main program structure is shown in FIG. 1.2.8. 
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FIG. 1 . 2.8 

ESL Graphical Representation of The Main Program for INTRPLAN 
or IPCAPTUR 


n J 




HAIN_LOOP 


Display_Data_Shell 


Setup_Conslants_And_Planetary_Ephemerides 


Save_Edited_input_on_disk 


Let_Useriedit_input_data 
evious_input_from_disk 


The decomposition of the main program(s) caused create two new 
procedures INNER_LOOP and MAIN_LOOP. Obviously, these two 
procedures have the format of a ESL sub program where, only 
module calls are allowed. But first we need to modify the module 
MAIN_LOOP. Introduction of a WHILE loop and to have a separate 
procedure for the portion shown in fig. 1.2.5 would be the main 
modifications. Fig. 1.2.9 illustrates the MAIN_LOOP after the 
modifications. 


procedure MAIN_LOOP is 

LOOP_END : boolean : = false; 

CONST : integer CONSTANT := 10 ; 

begin 

while LOO P_ END = false loop 

COMPUTE_PO S I TI ON_AND_VE LOC I T Y_OF_TARGET_P LANET { J ) 
INNER_LOOP; 

SET_CONTROL(J, LOOP_END, CONST); 
end loop; 

end MAIN_L00P; 
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FIG. 1.2.9 







where SET_CONTROL is another new procedure, created to 
incorporate the small portion of code shown in fig. 1.2.5. This is 
shown in FIG. 1.2.10 


procedure SET_CONTROL( J_IN : integer; DONE : boolean; CONST : integer) is 


begin 

J_IN := J_IN + 1; 
if J_IN > CONST then 
DONE := TRUE; 
end i f ; 

end SET_CONTROL; 


FIG. 1.2.10 

The benefit of making this modifications is that the software 
component SET_CONTROL is now converted to a reusable module. 
Hence this same module can be called by the procedure INNER_LOOP, 
by making similar modifications as done for the module MAIN_LOOP. 
Fig. 1.2.11 shows the modified procedure INNER_LOOP. 

procedure INNER_LOOP is 


LOOF_END : boolean := FALSE; 

CONST : integer CONSTANT := 16; 
begin 

while LOOP_END * FALSE loop 

C OM PUTE_POSITIO N_AND__VE LOC I T Y_0 F_H0ME_ PLANET ( I ) 

COMPUTE_TRAJECTORY_DATA ( l J I 

DISPLAY_VALUE ( TOTAL_DELTA__V , I , J ) 

CHECK_FOR_INTERRUPT_FROM_KEYBOARD ; 

SET_CONTROL ( J , LOOP_END, CONST); 
end loop; 
end INNER_LOOP; 

FIG 1.2.11 

It is now very clear that the two procedures INNER_LOOP and the 
MAIN_LOOP are converted into ESL subprograms. Figures 1.2.12 and 
1.2.13 illustrate the ESL graphical representation of the two 
subprograms. 


FIG. 1.2.12 

The ESL object graph for subprogram MAIN_LOOP 



FIG. 1 - 2.13 

The ESL object graph for subprogram INNER_LOOP 



The same ESL object graph could be used for BEST1WAY . It is 
important to make sure that the user set proper constant values 
when modules being called for individual applications. For example, 
the constant value passed into the reusable module SET_CONTROL, 
must be properly set inside procedures MAIN_LOOP and 
INNER_LOOP. i.e values 10 and 16 respectively for INTRPLAN and 
IPCAPTUR. Similarly, for BEST1WAY. 
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Comparatively, main program for POWERSWNG looks slightly 
different to the main programs of the other three applications. But of 
course, many of the modules already modified for reusable purposes 
can be used in designing ESL object graph for POWERSWNG. For 
POWRSWNG, the following procedure calls, must be added. 

COMPUTE_POSmON_AND_VELOCITY_OF_SWINGBY_PLANET 
COMPUTE_TRAJECTORY_FOR_FIRST_HELIOCENTRIC_LEG 
DISPL A Y_V ALUE 1 
DISPLAY_VALUE2 

COMPUTE_TRAJECTORY_FOR_SECOND_HELIOCENTRIC_LEG 

The following is the ESL graphical representation for POWRSWNG. 


FIG. 1.2.14 

ESL Object graph for main program of POWRSWNG 
















Jl 


Di8pl»y_Trl] ectory_dat«_of_i nt erect _to_user 


KMN_LOOP 

! ompu^^5° 8 i t i o n_a nd^ v e 1 oc i t y _o f _ t a i4j e t _j p 1 a n e t 


Display_data_shell 


Set _up_const ant s_and_planet ary _Ephemer idea 


Save_edited_inputs_on_di sk 


Let_user_edit_input_data 


Retrieve_previouc_inputs_from_diBk 





FIG. 1.2.15 

The ESL object graph for subprogram MAIN_LOOP 



FIG. 1.2.16 

The ESL object graph for subprogram INNER_LOOP of POWRSWNG 
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1.2.2 Modifications and Decomposition of Primitives. 

In ESL terms, Primitives are the modules that cannot be further 
decomposed or modules that are not worth decomposing. For 
example the module RETRIVE_PREVIOUS_INPUTS_FROM_DISK is a 
repeated module in all four applications in question. Though the 
module in POWRSWNG is slightly different to the module in other 
three applications, all four modules serve the same purpose. Further 
decomposition is out of question. Hence, best option is to have a 
single module that serves all four applications, making that a 
reusable component. Of course, to build a common reusable module, 
modifications are need to be carried out. 

Let us look into the modifications that have been done in order to 
make this module a reusable component. Originally, not a single 
parameter was passed into the procedure. As a major modification, 
two new parameters have been introduced namely FILE_NAME of 
type string and NAME.IN of type APPLICATION_TYPE 
APPLICATION_TYPE is a user defined type and initially has the 
enumerated type values INTRPLAN, IPCAPTURE, BEST 1 WAY, and 
POWRSWNG. NAME_IN passes in the appropriate value based on the 
application. FILE_NAME is the data.file name relevant to each 
application. In other words the corresponding data_file name for 
INTRPLAN is intrplan.get. Similarly others. Inside the module, CASE 
and IF_THEN_ELSE structures have been introduced to serve 
different application types. 

Modifications have been made to the following procedures in a 
similar manner. 

LET_U S ER_EDIT_INPUT_D AT A 
S A VE_ED ITED_INPUT_ON_D I S K 
KTLL_OUTDATED_INPUT_FTLE 
DISPLAY_LINE_LEADERS 
DISPLAY_FOOTER_LINES 

In each one of the above modules, a new input parameter of 
APPLICATION_TYPE is introduced. This parameter passes the name 
of the application that uses this module into the module. This helps 
to serve the needs of each application program. For instance, 
POWRSWNG performs a slightly different task in many of the above 
modules. Passing in the name of the application helps direct the 
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execution to the specific area within the module where those 
different tasks are carried out. 


1.2.3. Packages COMMON_MODULES, DATATYPES, DATA_TYPES_SPEC 

The packages COMMON_MODULES, DATATYPES, DAT A_TYPES_S PEC 
COMMON_MODULES are the three new packages introduced into the 
system. The services provided by these packages are described 
below. 

Package COMMON JVIODULES. 

This is a newly created package build to include all the common 
reusable procedures and functions. Also this package includes newly 
created reusable modules as a result of decomposition. For instance, 
the modules described in section 1.2.1 namely MAIN_LOOP, 
INNER_LOOP and SET_CONTROL, are residing in package 
COMMON_MODULES. Of course there are many more modules residing 
in this package, which we will be discussing later in this report. 

Package DATATYPES. 

This is also a newly created package to include all the type 
declarations and variable declarations, which are also repeated in all 
four applications. However this package includes only the data types 
and type declarations that are found in package bodies of all four 
application programs. 


Package DATA_TYPES_SPEC. 

This package is similar to the package DATA_TYPES. This package is 
created to include all the data types defined in the specifications of 
application programs. 
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It is important to make a note that packages DATATYPES and 
DATA_TYPES_SPEC are now directly reusable as all the application 
programs use these packages. 

1.2.4 Further Modifications. 


After a thorough analysis of the modules 

1 . COMPUTE_POSmON_AND_VELOCITY_OF_HOME_PLANET, 

2 COMPUTE_POSITION_AND_VELOCITY_OF_TARGET_PLANET , 

3 . COMPUTE_POSITION_AND_VELOCITY_OF_SWINGBY_PLANET, 

it was found that these modules are very similar and perform the 
same task. Therefore, it is obvious that, from these three modules a 
single reusable module can be built. 

procedure COMPUTE_POSITION_AND_VELOCITY_OF_HOME_PLANET ( I : integer ) is 
DT_SECS : FLOTE ; 


JDATE(HOME) := NOMJDATE(HOME) + LONG_FLOTE(I-8) * INTER VAL(HOME) 
DT_SECS := 86400.0 * FLOTE( JDATE(HOME) - PER_JDATE(HOME) ) 

PROP AG ATE_POS ITION_ AND_ VELOCITY_THRU_TIME ( 

PER.HELIPOS(HOME) , PER_HELIVEL(HOME) , DT.SECS , GM_SUNp(HOME) , 
HELIPOS(HOME) , HELIVEL(HOME) ) ; 

end ; 

FIG. 1.2.17 


procedure COMPUTE_POSITION_AND_VELOCITY_OF_TARGET_PLANET ( J : integer ) is 


DT.SECS : FLOTE ; 


JDATE(TARG) := NOM_JDATE(TARG) + LONG_FLOTE(J-5) * INTERVAL(TARG) 
DT_SECS := 86400.0 * FLOTE( JDATE(TARG) - PER_JDATE(TARG) ) ; 

PROPAGATE_POSmON_AND_VELOCITY_THRU_TIME ( 

PER_HELIPOS(TARG) , PER_HELIVEL(T ARG) , DT_SECS , GM_SUNp(TARG) , 
HELIPOS(TARG) , HELIVEL(TARG) ) *, 

end ’ 

FIG. 1.2.18 
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procedure COMPUTE_POSITION_AND_VELOCITY_OF_SWINGBY_PLANET ( J : integer ) is 


DT_SECS : FLOTE ; 


begin 

JDATE(SWBY) := NOM_JDATE(SWBY) + LONG_FLOTE(J-5) * INTERVAL(SWBY) 
DT_SECS := 86400.0 * FLOTE( JDATE(SWBY) - PER_JDATE(SWBY) ) ; 

PROPAGATE_POSITION_AND_VELOCITY_THRU_TIME ( 

PER_HELIPOS(SWBY) , PER_HELIVEL{SWBY) , DT.SECS , GM_SUNp(SWBY) , 
HELIPOS(SWBY) , HELIVEL(SWBY) ) ; 

end ; 


FIG. 1.2.19 


Shown above are the three procedures found in all four applications. 
As we have said earlier, simply these modules do the same task 
except for a few minor differences. The module shown below is a 
procedure built in order to perform all three tasks, and is reusable. 

procedure COMPUTE_POSITION_AND_VELOCITY_OF_PLANET ( I : integer; 

PLANET : PLANET_TYPE ; 

NAME : APPLICATION_TYPE ) is. 

D7_SECS : FLOTE * 

TEMP : TRAG_NODE 
COUNTER : integer; 

begin 

case PLANET is 

when TARGET j target = > TEMP ;= TRAG; 

if NAME = POWRSWNG then 





COUNTER 

I - 

6; 




else 






COUNTER 

I - 

5; 




end i f ; 



when 

HOME 1 

home 

=> TEMP :* HOME; 






COUNTER 

:= I - 

3; 

when 

SWNGBY 

I swngby 

=> TEMP ;3 SWBY ; 






COUNTER 

:= I - 

5; 

when 

others 


=> null; 




end case; 

if NAME = POWRSWNG AND DESTINATION =“ SWNGBY then 
JDATE (TEMP) : = NOM_JDATE (TEMP) ; 
else 

JDATE (TEMP) : = NOM_ JDATE (TEMP) + LONG_FLOTE (COUNTER) * INTERVAL ( TEMP ) 
end if; 

DT_SECS , := 86400.0* FLOTE ( JDATE (TEMP) - PER_JDATE (TEMP) ) 

PRO PAG AT E_ ? 0 S I T ION_AND_VELOC I TY_THRU_T I ME ( 

PER_HELIPOS (TEMP) , PER_HELIVEL (TEMP) , DT_SECS , GM_SUNp (TEMP) , 
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HELIPOS (TEMP) , HELIVEL (TEMP) ) 

end COMP UTE_PO S I T I ON_ AND_VE LOC I TY_0 F_P L ANET ; 

FIG. 1.2.20 


This new procedure is named COMPUTE_POSITION_AND_VELOCITY 
.OF.PLANET, and have three new parameters namely I of type 
integer, DESTINATION of type DESTINATION.TYPE and NAME.IN of 
type APPLI ATION_T YPE . DESTINATIONS YPE is also a user defined 
type and it defines the destination (HOME, TARGET or SWINGBY). 
APPLICATION_TYPE is the same type described earlier. 

At this point, it is important to make a note that, creating a new 
module by the name COMPUTE_POSITION_ AND. VELOCITY 
.OF.PLANET will change the corresponding object name in ESL object 
graph shown in section 1.2.2 


FIG. 1.2.21 

The ESL object graph for subprogram MAIN.LOOP 
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FIG. 1 . 2.22 

The ESL object graph for subprogram INNER_LOOP 



Similarly the object names 

compute_position_and_velocity_of_home_planet 

compute_position_and_velocity_of_target_planet 

compute_position_and_velocity_of_swingby_planet 

in figures 1.2.15, 1.2.16 and 1.2.18 for POWRSWNG will change 
accordingly. 

1.2.5 Modification of procedure COMPUTE_TRAJECTORY_DATA 


Compute_trajectory_data is a another procedure available in all four 
applications. A thorough analysis revealed that this procedure is an 
ideal module to decompose and convert into a ESL sub program. 
Decomposition had to be done so that the grains (decomposed 
components) could be reused in other similar modules throughout 
the applications. One major change made in reengineering this 
module is to eliminate exception handlers. May be this looks very 
inappropriate, but elimination of exception handlers was necessary 
to convert this module into a ESL sub program. We know that in ESL 
a sub program allows only a set of procedure or function calls . Also 
we need to realize that all these changes must be done having ESL in 
mind. At this point we need to think of how to tackle the granularity 
problem, i.e how big a grain is ?. The reason is that, when 
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& 

s™ decomposing the module, very small grains of size one, two or three 

■ lines remains within the module. In ESL terms, we cannot leave them 

within a module. We are forced to eliminate them and reside them in 

= separate modules. 

Let us take a look at how decomposition was done. FIG. 1.2.23 
H shows decomposed grains by drawing lines in between. Each grain is 

residing in a procedure with a appropriate procedure name. 


procedure COMPUTE_TRAJECTORY_DATA { I, 


integer 1 is 


TOCL-FAST : exception ; 

TOO_HOT : exception ; 


S INF AC : FLOTE ; 

TEST_VEC : VECTOR ; 

TF_DAYS : FLOTE ; 


e 


^3 



m 

1 


______ EXCEPTION_HANDLER_l 000 1 

TF_DAYS := FLOTE ( JDATE(TARG) - JDATE ( HOME ) ) 

if abs ( TF_DAYS ) <= 20.0 Chen 
raise TOO_FAST 
end if 

CALCULATIONS 


if 

TF_DAYS > 0, 

.0 



then DEP 

: = 

HOME 


else DEP 

: = 

TARG 


end if 



if 

DEP = HOME 




then ARR 

: = 

TARG 


else ARR 

: = 

HOME 


end if 




TF_SECS : = 86400.0 * abs ( TF_DAYS ) ' 

ANGMO_PREF : = HELIPOS(DEP) * HELIVEL f DEP ) 

TEST_VEC := HELIPOS ( DEP) * HELIPOS ( ARR) 7 — * gives cross product 

if TEST_VEC Sc ANGMO_PREF <0.0 & 9 ives doC product 

then SINFAC : = -ABS ( TEST_VEC ) 
else SINFAC := +ABS ( TEST_VEC ) 
end if 

XFR_ANG : = FULL_REVS*TWOPI + ATAN1 { SINFAC , HELIPOS (DEP) ScHELIPOS (ARR) ) ; 

DVALUE ( HELIOCENTRlC_TRANSFER_ANGLE }{I,J) := DATA_MATR I X_ INTEGER ( 

DEGPERRAD * XFR_ANG ) ; 

DVALUE C FLIGHT JTIME ) (I, J) :« DATA_MATRIX_INTEGER ( TF_DAYS } 


FIND_BEST_TRANSFER_TRAJECTORY 


■CALL_FOR_EXCEPTION_HANDLER_10003_10004 


if ( FULL_REVS > 0 ) and ( SMA_SIZE /= BEST_SIZE ) then 

SOLVE_LAMBERT_PROBLEM { HELIPOS (DEP) , TF_SECS, HELIPOS (ARR) , 
ANGMO_PREF , XFR.HELIVEL ( DEP) , XFR_HELIVEL (ARR) , 

GM_SUN , FULL_REVS, BEST__SI2E ) 

end if 

EXCEPTION_HANDLER_l 0002 


if ARR I VA L_S PEED_PENALTY >0.0 then 
raise TOO_HOT 
end i f 
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COMPUTE_HEL I OCENTR IC_TRAJECTORY_DATA f I, J } 
COMPUTE_P LANETOCENTR I C_DE PARTUR E_DATA { I, J ) 
COMPUTE_PLANETOCENTRIC_ARRIVAL_DATA ( l, J ) 


pragma page ; 


except ion 

when TOO_rAST => 

for KIND in DATA_KIND loop 

DVALUE ( KIND )(I,J) := 10001 

end loop 

when TOO_HOT => 

for KIND in MU LTI REV_5EMI MAJOR_AXIS . . APHELION_DI STANCE loop 
DVALUE ( KIND ) (I,J> := 10002 

end loop 

when LAMBERT_Z_ITERATION_FAILED_TO_CONVERGE => 

for KIND in MULTIREV_SEMIMAJOR_AXIS . . APHELIONJ)I STANCE loop 
DVALUE ( KIND ){I,J) 10003 

end loop 

when L AMB ERT_C ANNOT_ATT A I N_SP EC I F I ED_NUMBER_OF_R EV S => 

for KIND in MULT IREV_SEMIMAJOR_AXI S. -APHELION_D I STANCE loop 
DVALUE ( KIND }(I,J) := 10004 

end loop 

end 


FIG. 1.2.23 


All exceptions are handled within the same module where the 
exception is raised. For example , consider the newly created 
procedure EXCEPTION_HANDLER_10001. The exception is raised if 
the absolute value of TF_DAYS is less than t>r equal to 20.0. The 
module is reengineered in such a way that the sequence of 
instructions that are to be executed the moment this exception is 
raised are within the same procedure itself. This is illustrated in FIG. 
1.2.24. 


Procedure EXCEPT ION_HANDLER_10001 (TF_DAYS : flote; DONE s boolean; NAME : in 

APPLICATION_TYFE; CATEGORY ; CATEGOR Y_TYPE ) IS 


Begin 

if NAME = POWRSWNG then 
if CATEGORY = LEGl then 

TF_days := f lote ( Jdat e (SWBY) - JDATE (HOME) } ; 
if abs (TF_DAYS) <= 20.0 then 

for kindl in LEG 1_HEL I OCENTR IC_TRANS FER_ANGLE . . LEG1_FLIGHT_TIME loop 
VALUE1 (KINDI) (J) := 10001; 

end loop; 
end i f ; 

DONE : = true ; 

els if CATEGORY = LEG2 then 

TF_days := flote (Jdat e (TRAJ) - JDATE ( SWBY) ) ; 
if abs(TF_DAYS) <= 20.0 then 


for kindl in LEG2_HELI0CENTRIC_TRANSFER_ANGLE. . LEG2_FLIGHT_TIME loop 
'VALUE2 (KIND2) (I, J) : = 10001; 
end loop; 
end if; 

DONE := true; 
end if; 


else 

TF_days : = f lote ( Jdate (TRAG) - JDATE (HOME) ) ; 
if abs f TFJAYS) <= 20.0 then 

for kind in DATA_KIND loop 
DVALUE(KIND) (I,J) := 10001; 
end loop; 

DONE := true; 
end i f ; 
end if; 

end EXCEPTION_HANDLER_10001; 


FIG. 1.2.24 

The variable TF_DAYS should be passed-in from the module 
COMPUTE_TRAJECTORY_DATA because it is declared inside that 
module. Moreover, three new parameters NAME_IN, CATEGORY and a 
boolean variable DONE are passed into the module. CATEGORY is of 
user defined type CATEGORY_TYPE and have elements (LEG1 and 
LEG2). 

In the original code of this module, once the exception is raised, the 
execution is passed to the area where the exception is defined. Once 
that area is executed, the control will transferred to the end of the 
module. In the reengineered module, this is handled by a if-then- 
else structure. We have selected to introduce an if-then-else 
structure because ESL supports such structures. Hence the 
reengineered procedure COMPUTE_TAJECTORY_DATA will have the 
following format and is a sub program within ESL requirements. 


procedure COMPUTE_TRAJECTORY_DATA { I, J : integer > is 


S INF AC : FLOTE ; 

TESTJVEC : VECTOR ; 

TF.DAYS : FLOTE ; 

DONE_l , DONE_2 , DONE_3 : boolean : = false; 
DESTINATION^ : DESTINATION_TYPE := DEPARTURE; 
DESTINATION_A : DESTINATION_TYPE : = ARRIVAL; 
NAME : APPLICATION_TYPE: = INTRPLEC; 

CATEGORY : = DUMMY; 


begin 

EXCEPTION_HANDLER_10001 (TF_DAYS , DONE_l , NAME f CATEGORY); 
if DONE_l = false then 
CALCULATIONS (TF_DAYS, SINFAC, TEST_VEC) ; 

FIND JEST JTRANSFERJTRAJECTORY ; 

CALL_F OR_EXCEPT I ON_HANDLER_ 10003_10004 ( DONE_2 / CATEGORY , NAME ) ; 
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if DON E_2 = false then 

EXCEPT I0N_HANDER_1 0002 {DONE_3 , NAME) ; 
if DONE_3 = true then 

COMP UTE_HE L I OC ENT R I C _T RA JECTOR AT A { I, J, NAME } ; 

COMPUTE_PLANETOCENTRIC_ARRIVAL_OR_DEFARTURE_DATA ( I , J , DESTINATIONS, NAME) ; 
COMPUTE_PLANETOCENTRIC_ARRIVAL_ORJEFARTURESATA(I, J, destinations, NAME i 

end i f ; 
end if; 
end i f ; 

end COMPUTE_TRAJECTORY_DATA ; 

FIG. 1.2.25 


The corresponding ESL object graph diagram for the above sub 
program is shown in fig. 1.2.26. 


FIG. 1.2.26 

ESL OBJECT DIAGRAM FOR THE SUB PROGRAM COMPUTE_TRAJECTORY_DATA 



The ESL object graphs of the same sub program in BEST 1 WAY and 
POWRSWNG are slightly different to the above. The graph shown 
above is the ESL object graph for INTRPLAN. The ESL object graph 
for IPCAPTUR is almost the same except for less one procedure call( 
i.e exception_handler_10002). 
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In the original program code for the procedure 
COMPUTE_TRAJECTORY_DATA, we see two procedure calls by the 
names COMPUTE_PLANETOCENTRIC_DEPARTURE_DATA and 
COMPUTE_PLANETOCENTRIC_ARRIVAL_DATA. Since the two 
procedures do the same task, we could have one procedure to handle 
both situations and building another reusable module. 


procedure COMPUTE_PLANETOCENTRIC_DEPARTURE_DATA ( I,J : integer ) is 


DECL 

integer ; 

DELV 

FLOTE ; 

DV 

integer ; 

RASC 

integer ; 

VINHAT 

VECTOR ; 

VINMAG 

FLOTE 

VINVEC 

VECTOR ; 

VINF 

integer ; 


begin 


VINVEC 

= 

( XFR_HELI VEL { DEP ) -HELIVEL ( DEP ) ) 

*VBASE_ 

_M50 

_E ( DEP) 




VINMAG 

= 

ABS ( VINVEC ) 








VINHAT 

= 

VINVEC / VINMAG 







* 

DELV 

- 

DEPARTURE^ VELOCITY_INCREMENT 






» 

DV 

= 

DATA_MATR I X_ INTEGER ( 

DELV 

* 

100 

) 


? 

VINF 

= 

D AT A_MATR I X_I NTEGER ( 

VINMAG 

* 

100 

) 


; 

DECL 

= 

ROUND ( ASIN ( VINHAT (3) 



) * 

1800 / 

PI ) 



RASC 

= 

ROUND( ATANK VINHAT (2) 

VINHAT (1) 

) * 

1800 / 

PI ) 



DVALUE ( 

NOM I NA L_D E P A RTU R E_D E LTA_V 


) (I,J) 

: = 

DV 

; 

dkm/ 

sec 

DVALUE ( 

D EPARTURE_V_ I NF I N I T Y_MAGN ITUD E 

) ( I, J) 

: = 

VINF 

; 

dkm/ sec 

DVALUE ( 

DEPARTURE_V_INFINITY_DECLINATION 

) (I,J) 

: " 

DECL 

; 

0.1 

deg 

DVALUE ( 

DEPARTURE_V_INFINITY_RTASCENSION 

) (I, J) 

: = 

RASC 

; -- 

0.1 

deg 


end 


FIG. 1.2.27 


procedure COMPUTE_PLANETOCENTRIC_ARRIVAL_DATA { I,J : integer ) is 


DECL 

integer 

RASC 

integer 

VINHAT 

VECTOR 

VINMAG 

FLOTE 

VINVEC 

VECTOR 

VINF 

integer 

SPEED 

FLOTE 

SPD 

integer 


begin 

VINVEC := ( XFR_HELIVEL (ARR) -HELIVEL (ARR) } *VBASE_M50_E ( ARR) 
VINMAG : = ABS { VINVEC ) 

VINHAT := VINVEC / VINMAG 
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SPEED 

SPD 

VINF 

DECL 

RASC 

DVALUE 

D VALUE 

DVALUE 

DVALUE 

end 


= SQRT ( VESQ(ARR) + V I NMAG * V I NMAG } 

= DATA_MATR I X_ INTEGER { SPEED 

= DATA_MATR I X_ INTEGER ( VINMAG 

= "ROUND { AS IN ( V INHAT l 3 5 

= ROUND f ATAN1( V INHAT ( 2 } , V] 

ARR I VAL.SPEED ) ( I , J) 

ARR I VAL_V_INFTNITY_MAGN I TUDE ) ( I , J) 

ARRIVAL_V_INFTNlTY_DECLINATION in, J) 


( ARR I VA L.V. I NF I NI T Y_RTA SC ENS I ON )(I ( J } 


NKAT ( I } } 
SPD 
' VINE 
DECL 
RASC 


IOC 

100 

1300 

1300 


) 

) 

' PI ) 

’ PI ) 

-- dkirn 
- - dkm -■ 
-- 0.1 
-- 0.1 


sec 

deg 

deg 


FIG. 1.2.28 


procedure COMPUTE. PLANETOCENTR I C.AR RIVAL_OR_DETARTURE.DAT A f I, J : integer; 

DESTINATION : DESTINATIO N.TY ? 
NAME: APFLICATION.TYFE) is 


DECL : integer; 

RASC : integer; 

VINHAT: VECTOR; 

VINMAG: FLOTE; 

VINVEC: VECTOR; 

VINF ; integer; 

DV_OR.SPD : integer; 

TEMP: TRAJ.NODE; 

NDDV.OR.AS : ; 

DVIM.OR.AVIM: ; 

DVID.OR.AVI D : ; 

DVIR_OR_AVIR; 

TOT.DELV: flote; 

TOT.DV : integer; 

begin 

case DESTINATION is 

when DEPARTURE I departure => TEMP := DEP; 
when ARRIVAL I arrival => TEMP := ARR; 

end case; 


VINVEC := (XFR HELIVEL (TEMP) - HELIVEL (TEMP) ) *VBASE M50 E ( TEMP } ; 
VINMAG := ABS { VINVEC > ; 

VINHAT := VINVEC f VINMAG; 
if DESTINATION = DEPARTURE then 

DELV OR SPEED DEPARTURE VELOCITY INCREMENT; 
if NAME = IPCAPTURE then 

TOT.DELV := ARRIVAL.VELOCITY. INCREMENT + DELV.OR.SPEED; 
TOT.DV := DATA.MATRIX.INTEGER (TOT.DEV * 100) ; 
end i f ; 


NDDV.OR.AS 
DVIM.OR.AVIM 
DVID.OR.AVID 
DVIR.OR.AVI R 
elsif DESTINATION 
DELV.OR.SPEED 
DELV.OR.SPEED 
NDDV_OR_AS : = 
DVIM.OR.AVIM 
DVID.OR.AVID 
DVI R.OR.AVI R 
end if; 


:= NOMINAL.DEPARTURE DELTA.V; 

DEPARTURE.V.INF INITY.MAGNI TUDg ; 

: = DEPARTURE.V.INF I NITY.DECLI NATION; 

• : = DEPARTURE.V.I NF I N ITY.RTASCENS ION ; 

= ARRIVAL then 

: = SQRT (VESQ (TEMP) + VINMEG*V~MEG) ; 

:= MIN ( DELV.OR.SPEED , MAXAVELMAG (TEMP) ; 
ARRIVAL.SPEED; 

= ARRIVAL.V.INFINITY.MAGNITUDE; 

= ARRIVAL.V.INFINITY.DECLINATION; 

= ARRIVAL.V.INFINITY.RTASCENSION; 


DV_OR_SPD := DATA.MATRIX.INTEGER ( DELV.OR.SPEED * 100); 
VINF := DATA.MATRIX.INTEGER (VINMAG * 100); 

DECL := ROUND (AS IN { VINHAT(3) ) * 1800/ PI ) ; 
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RASC := ROUND { ATANI f VINHAT (21# VINHAT [ I ) » * 1800 / PI 

if NAME IPCAPTURE Chen 

D VALUE f NDDV_OR_AS J(I,J) := DV_OR_SPD ; -- dkrn/sec 
D VALUE { NDDV_OR_AS ) (I, J) := DV_OR_SPD ; -- dkrn/sec 
DVALUE f DVIM_OR_AVIM 1 (I,J) VINF ; -- dkrn/sec 
D VALUE ( DVID_OR_AVID )(I,J) := DECL ; -- 0.1 deg 

DVALUE ( DVIR_OR_AVIR }(I,J) :» RASC ; -- 0.1 deg 

end i f 


FIG. 1.2.29 

The figures 1.2.27 and 1.2.28 show the two procedures in question. 
Fig. 1.2.29 is the modified procedure built to represent both the 
procedures shown in figures 1.2.27 and 1.2.28. This procedure 
replaces 8 modules in all four a pp lications. And hence, it is reusable. 
In order to make this a reusable module, new variables have been 
introduced along with the necessary modifications. This procedure 
also resides in the package common_modules which is designed to 
reside all the newly created, and modified modules. 

Procedure COMPUTE_TRAJECTORY_FOR_FIRST_HELIOCENTRIC_LEG, 
and COMPUTE_TRAJECT OR Y_FOR_SECOND_HEL!OCENTRIC_LEG are 
available only in applications BEST 1 WAY and POWRSWNG. However 
the procedure in POWRSWNG is very similar to the procedure 
COMPUTE_TRAJECTORY_DAT A in INTRPLAN & IPCAPTURE. Hence this 
procedure in POWRSWNG can be replaced by already designed 
reusable components and made a separate ESL object graph. But as 
we have done in earlier cases, these two procedures in BEST1WAY 
have been modified and built one single reusable procedure named 
COMPUTE_TRAJECT ORY_FOR_FIRST_ AND_SECOND_ 
HELIOCENTRIC_LEG. The following figures show the modifications. 

procedure COMPUTE JTCAJECTORY.FOR.HRSTJHELIOCENTRIC.LEG is 


ANGMO.PREF : VECTOR ; 
TFl.DAYS : FLOTE ; 
TF1.SECS : FLOTE ; 


begin 

TFl.DAYS := FLOTE( JDATE(SWBY) - JDATE(DEP) ) ; 

TF1_SECS := 86400.0 * TF1.DAYS ; 

ANGMO.PREF := HELIPOS(DEP) * HELIVEL(DEP) ; 

SOLVE_LAMBERT_PROBLEM ( HELIPOS(DEP), TFl.SECS, HELIPOS(SWBY), 
ANGMO.PREF, 

XFR_HELIVEL(DEP), XFR_HELIVEL(SWBY), GM_SUN ); 
ANTE_SWBY_VTNVEC := XFR_HELIVEL(SWBY) - HELIVEL(SWBY) 
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end 


FIG. 1.2.30 

procedure COMPUTE_TRAJECTORY_FOR_SECOND_HELIOCENTRIC_LEG is 


ANGMCLPREF : VECTOR ; 
TF2_DAYS : FLOTE ; 
TF2_SECS : FLOTE ; 


begin 

TF2.DAYS := FLOTE( JDATE(ARR) - JDATE(SWBY) ) 

TF2.SECS := 86400.0 * TF2JDAYS ; 

ANGMO PREF : = HELIPOS(ARR) * HELIVEL(ARR) ' ' ; 

SOLVE LAMBERT.PROBLEM ( HELIPOS(SWBY), TF2_SECS, HELIPOS(ARR), 
ANGMO.PREF, 

XFR.HELIVEL(SWBY), XFR_ IIELIVEL(ARR), GM_SUN ); 
POST_SWBY_VINVEC := XFR.HELIVEL(SWBY) - HELIVEL(SWBY) 
end ! 

FIG. 1.2.31 


The following is the modified version of the above two modules. 

procedure COMPUTE_TRAJECTORY_FOR_FIRST_AND_SECOND_HELIOCENTRIC_LEG (CATEGORY : 

CATEGORY.TYPE) is 

-- THIS IS A REUSABLE COMMON. MODULE FOR COMPUTE.TRAJECTORY_FOR.FIRST.HELIOCENTRTC.LEG 
COMPUTE.TRAJECTORY_FOR_SECOND_HELIOCENTRIC.LEG -- 
-- CHANGES HAVE BEEN MADE ACCORDINGLY. 

ANGMO.PREF ; VECTOR ; 

TFI.DAYS : FLOTE ; 


begin 

if CATEGORY = LEG1 then 

TFI.DAYS := FLOTE ( JDATE t SWBY } - JDATE (DEP) } 

ANGMO.PREF : = HELIPOS (DEP) * HELIVEL (CEP ) 

SOLVE. LAMBERT.PROBLEM (HELIPOS ( DEP) , TFi.DAYS* 36400.0, HELIPOS ( SWBY ) , 
ANGMO.PREF, XFR.HELIVEL (DEP ) , XFR.HELIVEL (SWBY) , GM.SUN ); 
ANTE.SWBY.VINVEC := XFR.HELIVEL ( SWBY) - HELIVEL ( SWBY) 


else 

TFI.DAYS := FLOTE ( JDATE (ARR) - JDATE (SWBY) ) 

ANGMO.PREF := HELIPOS (ARR) * HELIVEL (ARR) 

SOLVE.LAMBERT.PROBLEM ( HELIPOS ( SWBY) , TFI.DAYS * 86400.0 , HELI PCS { ARR) , 
ANGMO.PREF, XFR.HELIVEL { SWBY) , XFR.HELIVEL (ARR) , GM.SUN ); 

POST.SWBY.VINVEC := XFR.HELIVEL ( SWBY) - HELIVEL { SWBY) 
end if; 

end ; 
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1.2.6 Application BEST 1 WAY 


A few modules in BEST1WAY do not match with any of the modules 
in either POWRSWNG or INTRPLAN or IPCAPTUR. These modules 
cannot be made reusable because they are unique only to 
BEST 1 WAY. 

Therefore the following modules remain same in the application 
BEST 1 WAY. 

FIND_BEST_DIRECT_TRANSFER_TRAJECTORY 
FIND_BEST_SWING_BY_TRAJECTORY 
ISOLATE JJNPOWERED_SWINGBY_SOLUTION 
COMPUTE_PLANETOCENTRIC_SWINGBY_TRAJECTORY_DATA 

1.2.7 Application POWRSWNG 

As in BEST1WAY, POWRSWNG also has a few unique modules that 
are used nowhere else. Since these modules cannot be made 
reusable, they remain unchanged within the application itself. 

Hence the modules 

COMPUTE_LEG 1 _PLANET 0CENTR1C_TRAJECT OR Y_D AT A 
COMPUTE_LEG2_PLANET OCENTRIC_TRAJECT OR Y_D AT A 
COMPUTE_PLANET OCENTRIC_S WINGB Y_TRAJECTORY_D AT A 

remain unchanged. 


1.2.8 Module DATA_MATRIX_INTEGER 

Module DATA_MATRIX_INTEGER is one common module found in all 
four applications. This module can be used in all applications without 
any modifications. Therefore this module has been shifted into the 
package COMMON_MODULES where all the reusable common modules 
reside. 


1.2.9 Complete ESL object graphs for all four applications. 

This section provides full ESL object graphs for all four applications. 
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ESL object dependency graph for PO’ 





ESL Object graph for main program of INTRPLAN ESL object graph for COMPUTE TRAJECTORY^ DATA 

for INTRPLAN 



ESL object dependency graph for II 




ESL object graph for COMPUTE_TRAJECTORY_DATA 



ESL object dependency graph for I) 









Lessons Learned About the Current ESL Tool 


ESL graphs are similar to data flow diagrams, but also have 
control flows and two additional constructs: loop and if-then. 

ESL does not currently have any configuration management 
functions or any verification and validation functions. 

Current attributes of the components are insufficient; 
particularly, there are no attributes (slots) for providing the 
purpose of a component. 

There are several important reuse questions that must still be 
answered before ESL can be a truly effective reuse system. 
What standards should reusable components meet before they 
are accepted as ESL components? What makes a component 
reusable? As ESL is targeted toward an engineer rather than a 
programmer, should not the engineer see mostly domain- 

oriented components instead of computer-science oriented 
components while searching the library of components? 

FOR loops are not supported, only WHILE loops. In the ESL 
system, the looping structures are restricted only to WHILE 

loops. This is a severe draw back. It was found that, during the 
reengineering process, all the FOR loops in the subprograms 

had to be changed into WHILE loops. In order to do this, more 
modules had to be created (because ESL only connects modules 
and does not allow for the direct insertion of even small pieces 
of code); specifically, an unnecessary module had to be created 
to increment the iterated value for the new WHILE loop. If 

there were ESL facilities to implement FOR loops, this 
unnecessary creation of modules could have been avoided. 

Another shortcoming found in the ESL graphs was the lack of 
directional labelling. For example, there are two directions 
emerging from an IF node: THEN and ELSE. The ESL graphs do 
not label these directions, causing great confusion. 

A few serious syntax errors were found in the generated Ada 
code. 


• When an existing graph is modified, the user is given two 

options when exiting the graph: save or delete. There is no 
option to exit the graph without making any permanent 
changes to it. Furthermore, if the delete option is selected, the 
graph is deleted from the knowledge base, but the associated 
drawing file, called "graphname.dwg," is not removed from the 
file system. 

• Drawing files are not always kept consistent with the 

knowledge base. 

• The graph editor panel cannot be resized. 

• The connector drawing algorithm is too simple and needs to be 
improved. 

• When a node is deleted on the drawing panel, that object still 
appears on the "Node on graph" panel. 
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